Computer implemented systems and methods for assessing operational risks and mitigating operational risks associated with using a third party software component in a software application

ABSTRACT

Methods and systems are disclosed for automatically assessing and mitigating operational risks associated with using a software component in a software application. As a part of a method, one or more software components of the software application is accessed and software component characteristic information is received about each of the one or more software components, responsive to the accessing. The software component characteristic information includes information about a characteristic of a software component that is related to an operational risk associated with using the software component in the software application. Responsive to receiving the software component characteristic information, and based on the software component characteristic information, operational risk assessment information is generated using one or more rules. The generated operational risk assessment information is outputted where at least one step of the method is performed by a processor.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.15/209,580, filed Jul. 13, 2016, the contents of which are hereinincorporated by reference in their entirety.

FIELD OF THE DISCLOSURE

Aspects of the disclosure relate to a computer implemented system, andmethod, for assessing operational risks and mitigating operational risksassociated with using a third party software component in a softwareapplication.

BACKGROUND

Conventional software development systems require a lot of manual effortfrom Developers who collaborate on software projects. A Scrum team is ateam of Developers that collaborate on complex software projects.Whenever a third party library is added to a software project aspreadsheet is updated by the Scrum team. This process places theresponsibility of updating the spreadsheet on each Developer. This taskmay be forgotten or neglected when a Developer is faced with apressurized deadline. As such, there is no guarantee that unapprovedthird party software versions are used or have made their way into thesoftware product without some manual form of validation. Manualvalidation of third party software is extremely time consuming. As such,security vulnerabilities within older versions of plugins, or newerones, may not be identified.

In a conventional approach, a Build Engineer or equivalent, reviews theentire code-base after a build, gathers the artifacts, andpainstakingly, manually and visually, examines each artifact andcompares them to the spreadsheet. This can take a number of days orweeks to complete. And, mistakes can easily be made that can expose theDeveloper to litigation. To find vulnerabilities or legacy plugins ordeprecated plugins, one or more individuals would have to analyze theold plugins manually, which may not be possible without support.

SUMMARY

Conventional approaches to validating third party software can requireone or more individuals to analyze old plugins manually which may not bepossible without support. A method for automatically assessing andmitigating operational risks associated with using a software componentin a software application is disclosed that addresses the aforementionedshortcomings of conventional technologies. However, the claimedembodiments are not limited to implementations that address any or allof the aforementioned shortcomings. As a part of the method, one or moresoftware components of the software application is accessed and softwarecomponent characteristic information is received about each of the oneor more software components, responsive to the accessing. The softwarecomponent characteristic information includes information about acharacteristic of a software component that is related to an operationalrisk associated with using the software component in the softwareapplication. Responsive to receiving the software componentcharacteristic information, and based on the software componentcharacteristic information, operational risk assessment information isgenerated using one or more rules. The generated operational riskassessment information is outputted where at least one step of themethod is performed by a processor.

It will be appreciated that the above summary is provided merely forpurposes of summarizing some example embodiments so as to provide abasic understanding of some aspects of the disclosure. As such, it willbe appreciated that the above described example embodiments are merelyexamples of some embodiments and should not be construed to narrow thescope or spirit of the disclosure in any way. It will be appreciatedthat the scope of the disclosure encompasses many potential embodiments,some of which will be further described below, in addition to those heresummarized. Further, other aspects and advantages of embodimentsdisclosed herein will become apparent from the following detaileddescription taken in conjunction with the accompanying drawings whichillustrate, by way of example, the principles of the describedembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described the disclosure in general terms, reference willnow be made to the accompanying drawings, which are not necessarilydrawn to scale, and wherein:

FIG. 1A shows an exemplary software development environment for a systemfor third party software risk analysis and mitigation according to oneembodiment.

FIG. 1B shows elements of a user interface of a system for third partysoftware risk analysis and mitigation according to one embodiment.

FIG. 2A is a functional block diagram that shows functional blocks anddata structures of a system for third party software risk analysis andmitigation according to one embodiment.

FIG. 2B is a block diagram that illustrates how policies relate to rulesthat are used by a third party software rules engine according to oneembodiment.

FIG. 2C is a diagram that shows characteristics of third party softwarethat are detected for risk analysis and mitigation according to oneembodiment.

FIG. 3 shows a flowchart of the steps performed in a method forautomatically assessing operational risks and mitigating operationalrisks associated with using a software component in a softwareapplication according to one embodiment.

FIG. 4 is a diagram of an example computing system that may be used toimplement some example embodiments of a system for third party softwarerisk analysis and mitigation.

DETAILED DESCRIPTION

Although the present invention has been described in connection with oneembodiment, the invention is not intended to be limited to the specificforms set forth herein. On the contrary, it is intended to cover suchalternatives, modifications, and equivalents as can be reasonablyincluded within the scope of the invention as defined by the appendedclaims.

In the following detailed description, numerous specific details such asspecific method orders, structures, elements, and connections have beenset forth. It is to be understood however that these and other specificdetails need not be utilized to practice embodiments of the presentinvention. In other circumstances, well-known structures, elements, orconnections have been omitted, or have not been described in particulardetail in order to avoid unnecessarily obscuring this description.

References within the specification to “one embodiment” or “anembodiment” are intended to indicate that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention. Theappearance of the phrase “in one embodiment” in various places withinthe specification are not necessarily all referring to the sameembodiment, nor are separate or alternative embodiments mutuallyexclusive of other embodiments. Moreover, various features are describedwhich may be exhibited by some embodiments and not by others. Similarly,various requirements are described which may be requirements for someembodiments but not other embodiments.

Some portions of the detailed descriptions, which follow, are presentedin terms of procedures, steps, logic blocks, processing, and othersymbolic representations of operations on data bits within a computermemory. These descriptions and representations are the means used bythose skilled in the data processing arts to most effectively convey thesubstance of their work to others skilled in the art. A procedure,computer executed step, logic block, process, etc., is here, andgenerally, conceived to be a self-consistent sequence of steps orinstructions leading to a desired result. The steps are those requiringphysical manipulations of physical quantities. Usually, though notnecessarily, these quantities take the form of electrical or magneticsignals of a computer readable storage medium and are capable of beingstored, transferred, combined, compared, and otherwise manipulated in acomputer system. It has proven convenient at times, principally forreasons of common usage, to refer to these signals as bits, values,elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing terms such as “accessing” or “generating” or“outputting” or the like, refer to the action and processes of acomputer system, or similar electronic computing device that manipulatesand transforms data represented as physical (electronic) quantitieswithin the computer system's registers and memories and other computerreadable media into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

FIG. 1A shows an exemplary software development environment for a system200 for third party software risk analysis and mitigation according toone embodiment. In the FIG. 1A embodiment, the exemplary softwaredevelopment environment includes server 120, internet 130, developerworkstations 101 a-101 n and system 200.

Referring to FIG. 1A, in one embodiment, system 200 can be a part of, oroperate cooperatively with, project management software that executes oncentral server 120. In such environments, software developer projectscan be replicated to a team of project developers working on theproject, through central server 120, to developer workstations 101 a-101n, that are located both locally and via the internet 130. In otherembodiments, system 200 can be part of a single user system thatoperates as a desktop application. In one embodiment, when a build iscompleted, system 200 can access the build and examine the third partysoftware components of the build. Based on the examination, a riskassessment score, and a risk mitigation report, can be generated. In oneembodiment, this information can be provided to the developer(s) workingon the build to assist in its finalization.

In one embodiment, as a part of the aforementioned risk assessment andrisk mitigation functions, system 200 assesses risks related tocharacteristics of third party software that can include but are notlimited to currency, consistency, security score, usage and bill ofmaterials, versions, license type and legal. System 200 uses informationrelated to the aforementioned third party software characteristics toidentify and address in an automated manner issues that are notaddressed by conventional manual approaches to the examination of thirdparty software. For example, in one embodiment, system 200 determinescurrency of usage of third party software by comparing the third partysoftware that is being used with published versions of the third partysoftware. In addition, system 200 identifies the third party softwarethat should be given priority for purposes of upgrades. In oneembodiment, system 200 identifies the third party software that shouldbe given priority for purposes of upgrades based on information thatincludes but is not limited to third party policy definitions,consolidated lists of issues for third party software (machine learning)and new third party versions available. Moreover, system 200 determinessecurity issues related to third party software usage by examiningplugins and third party policy definitions. In an additional way ofaddressing issues not addressed by conventional systems, system 200generates a third party risk analysis score and determines ways toanticipate the degradation of the risk analysis score. In oneembodiment, system 200 can generate a third party risk analysis scoreand determine ways to anticipate the degradation of the risk analysisscore based on end of life dates of third party software and deprecationtags of application program interface (API) usage. In a yet additionalway of addressing such issues, system 200 identifies third partysoftware that is not used in end products by generating a bill ofmaterials and executing runtime analysis and build time analysis toidentify the unused third party software. Furthermore, system 200provides notice of a change in license of a third party product that isbeing used based on a detected change in license model between opensource versions.

Accordingly, the automated functionality of system 200 eliminatesdeveloper responsibility for manually identifying securityvulnerabilities by automating the analysis of third party software andthe provision of a risk assessment score and a risk mitigation plan.

FIG. 1B shows elements of an exemplary user interface 140 of system 200(see FIG. 1A) for third party software risk analysis and mitigationaccording to one embodiment. The interface provides a visualrepresentation of third party components of builds and characteristicsof the third party components of builds that can indicate securityvulnerability. For example, referring to FIG. 1B, third party softwarelicense chart 150 and third party software version chart 160 provides auser with a convenient view of useful third party licensing and versioninformation. In the FIG. 1B embodiment, the individual segments of thecharts correspond to third party components of a build. The segments canbe configured (e.g., colored, labelled) to provide licensing and versioninformation data, for the corresponding third party components. Forexample, in the case of licensing, a segment can be configured toindicate whether a third party component is licensed or open source.And, in the case of version information, segments can be configured toindicate whether there are multiple versions of third party software orincompatible versions of third party software. In addition, oralternatively, user interface 140 can include tables with fields wherecharacteristics of third party software that can be used to determinesecurity vulnerability are expressly characterized. For example,referring again to FIG. 1B, a table that includes component name 170,component version 172, latest version 174 and license 176 fields can beincluded where specified characteristics of first third party software178 and second third party software 179 are expressly characterized. Inaddition, in one embodiment, user interface 140 (or a similar userinterface) can support the automated risk assessment and mitigationreporting that is done by system 200 (see FIG. 1A), and described indetail herein, by presenting this information in a manner that enablesthe straightforward access to and use of it by software developers (notshown in FIG. 1B). It should be appreciated that the user interfaceconfiguration that is shown in FIG. 1B is only exemplary. Accordingly,in other embodiments, other manners of suitably presentingcharacteristics of the third party software components of builds thatcan indicate security vulnerability can be employed.

FIG. 2A is a functional block diagram that shows functional blocks anddata structures of system 200 for third party software risk analysis andmitigation according to one embodiment. The functional blocks of system200 implement an algorithm for third party software risk analysis andmitigation according to one embodiment. In the FIG. 2A embodiment,functional blocks of system 200 include characteristic examinationcomponents 205, rule engine 209 and risk assessment database 215(optional).

Referring to FIG. 2A, software code 201 is used to develop a softwareapplication build 203 a and/or 203 b that can be analyzed by system 200.In one embodiment, the software code that is used in the softwareapplication build can include but is not limited to, one or more of,Java source code 201 a, Python code 201 b, C/C++ code 201 c andJavascript/UI code 201 d parts. In one embodiment, the softwareapplication builds can include but are not limited to maven based builds203 a and npm+bower based builds 203 b. In one embodiment, theaforementioned builds are accessed by system 200 and examined toidentify third party software components of the builds. In oneembodiment, the third party software components are examined todetermine the absence or presence of specified characteristics usingcharacteristic examination components 205. In the FIG. 2A embodiment,the software characteristic examination components include dependencyexamination component 205 a, license examination component 205 b,dependency plugin examination component 205 c, license UI examinationcomponent 205 d, common vulnerabilities and exposures (CVE) examinationcomponent 205 e, outdated tool examination component 205 f and retirejsexamination component 205 g. Dependency examination component 205 aexamines third party software for dependencies, license examinationcomponent 205 b examines third party software for licenses, dependencyplugin examination component 205 c examines third party software fordependency plugins, license UI examination component 205 d examinesthird party software for UI licenses, CVE examination component 205 eexamines third party software for a CVE score, outdated tool examinationcomponent 205 f examines third party software for outdated componentsand retire.js 205 g examines third party software for knownvulnerabilities. However, these software characteristic examinationcomponents are only exemplary, as many other characteristics can beexamined for risk analysis and mitigation purposes as is discussed indetail herein with reference to FIG. 2C.

Referring again to FIG. 2A, the outputs 207 a-207 g of third partysoftware characteristic examination components 205 are accessed by athird party rules engine 209. In one embodiment, third party rulesengine 209 uses rules in the provision risk assessment scores 211 andrisk mitigation plans 213 based on accessed characteristics. In oneembodiment, the risk assessment scores can be stored in risk assessmentdatabase 215. In one embodiment, the rules that third party rules engine209 uses are based on lists of approved third party products 217 andthird party policy definitions 219, 221, that are compiled byorganization staff (e.g., legal, developer) that are tasked withproducing this information.

In one embodiment, policies can be set, such as by a policy intern orother staff member via the input of information into a field that can bea part of a user interface associated with system 200. The policies canbe accessed by third party rules engine 209 and used to provide overallrisk assessment scores 211 and risk mitigation plans 213. For example,consider the case where a field that sets policy regarding the currencyof third party software is set using the following or similar entry:

-   -   Latest Version−Major=1

In one embodiment, such a setting can be used to indicate that being onemajor version behind the latest version in production is tolerable butbeing more than one major version behind the latest version inproduction (e.g., two behind the latest version) requires a warning. Inone embodiment, third party rules engine 209 is able to determine andquantify any difference between the current third party software versionand the latest third party software version. Next, consider the casewhere a field related to the currency of a third party softwarecomponent of a build is set using the following or similar entry:

-   -   Latest Version−Minor=10

In one embodiment, such a setting can be used to indicate that being tenminor versions behind the latest third party software version inproduction is tolerable but being more than ten major versions behindthe latest third party software version in production (e.g., 10 behindthe latest version) requires a warning. In one embodiment, third partyrules engine 209 can quantify any difference between the current thirdparty software version (e.g., currently used) and the latest third partysoftware version. In one embodiment, policies such as those discussedabove, can be the basis for rule formulation. The formulation of rulesbased on such policies is discussed below with reference to FIG. 2B.

FIG. 2B is a block diagram that illustrates how rules that are used bythe third party rules engine of exemplary embodiments, such as thirdparty rules engine 209 in FIG. 2A, are determined. Referring to FIG. 2B,according to one embodiment, a policy 1 241 and a policy 2 243 can becombined to derive a rule 1 251, a policy 1 241 alone can be used toderive a rule 4 249, policy 2 243 alone can be used to derive a rule 3247 and a policy 3 245 alone can be used to derive a rule 2 253. Asshown in FIG. 2B, in some cases where third party softwarecharacteristics information that is received by the rules engine causesa rule such as rule 1 251 to be used to determine risk, rule 2 253 canbe implicated as an option to appropriately determine risk (e.g., wherepolicies 1, 2 and 3 are involved). A practical illustration of how rulesmay be formulated from policy definitions is provided below.

The following are exemplary rule formulations based on policydefinitions of the form discussed above with reference to FIG. 2A. Thesetype rule formulations are the basis for third party software riskassessments, when particular characteristics of third party softwarecomponents that are indicated by organization policy to be examined forrisk, are detected. For example, in one embodiment, as regards thirdparty software currency, an exemplary formulation of rules can includethe following or similar rule formulations: (1) if the version number ofa major version of the third party software is less than the latestversion number of the third party software and is determined to be twomajor versions behind the latest version of the third party softwarethen provide a red flag assessment that indicates non-compliance withown policy metric, (2) if the version number of a major version of thethird party software is less than the latest version number of the thirdparty software and is determined to be one major version behind thelatest version of the third party software then provide a yellow flagassessment that indicates an early action identifier, (3) if the versionnumber of a minor version of the third party software is less than thelatest version number of the third party software and is determined tobe eight major versions behind the latest version of the third partysoftware then provide a yellow flag assessment that indicates an earlyaction identifier, (4) if the version number of a minor version of thethird party software is less than the latest version number of the thirdparty software and is determined to be ten major versions behind thelatest version of the third party software then a yellow flag assessmentis provided that indicates non-compliance with own policy metric, and(5) for a current version number of the third party software, if thesecurity score is greater than 7.5 (a known CVE risk threshold) and theversion number of the third party software is equal to the latestversion number of the third party software, an early action identifieris issued. As shown by these exemplary rules, in one embodiment, rulescan be formulated and derived directly from policy definition premises.

It should be appreciated that the aforementioned rule formulations areonly intended to be exemplary, and are presented to demonstrate howrules related to third party software currency can be formulated basedon relevant underlying policies. However, in one embodiment, policiesare defined, and rules formulated, for each of the herein describedthird party software characteristics that are examined.

In one embodiment, when the above described analysis of the third partysoftware components of a build has been completed, and a report has beenmade available that identifies third party software components that arenot compliant with company policies, a mitigation metric, e.g., earlyaction identifier, update warning, which enables third party rule engine209 to provide better input, can be generated. For example, again usingthe third party software currency characteristics context, in oneembodiment, for the current version number, if the third party softwaresecurity score is greater than a predetermined threshold number, e.g.,7.5 (a known CVE risk threshold) and if the current third party softwareversion number and the latest third party software version number areequal, an early action identifier can be generated. Moreover, in oneembodiment, for the current version number, if the third party softwaresecurity score is greater than a predetermined threshold number (e.g.,7.5), and if the current third party software version number is lessthan the latest third party software version number and the latestversion has its security vulnerability resolved, a warning that anupdate is required (e.g., mitigation provided) can be generated. Inaddition, in one embodiment, for the current version number, if thesecurity score is greater than a predetermined threshold number (e.g.,7.5) and if the current version number is less than the latest versionnumber and the security vulnerability is not resolved in the latestversion, an early warning notification that the risk still exists can begenerated (no mitigation plan provided). In one embodiment, this riskmitigation information can be provided to the developer(s) as a part ofthe provision of real time warnings and mitigation plans.

Using the methodology described above, exemplary embodiments addressmany of the problems that are encountered using conventional approaches.For example, exemplary embodiments enable software developers todetermine the currency of their usage of third party software. In oneembodiment, system 200 accomplishes this by comparing current thirdparty software usage (the versions of third party software currentlybeing used) to published versions of the software. In addition,exemplary embodiments enable software developers to determine the thirdparty software that they should prioritize for upgrade in their next fixpack. For example, system 200 provides complex recommendations based onelements that include but are not limited to third party policydefinitions, consolidated list of issues for third party software(machine learning) and new third party versions that are available. Aswell, exemplary embodiments enable software developers to determine anysecurity issues tied to their usage of third party software. In oneembodiment, system 200 can use CVE plugins and third party policydefinitions to determine the security issues that are tied to usage ofthird party software. Likewise, exemplary embodiments enable softwaredevelopers to determine an overall third party threat/risk analysisscore and to anticipate when the score will degrade. In one embodiment,in order to determine the overall third party threat/risk analysis scoreand to anticipate when the score will degrade, system 200 uses end oflife dates of third party software and deprecation tags of API usage.Furthermore, exemplary embodiments enable software developers todetermine whether to ship third party software with a product when thethird party software is not used in the end product. In one embodiment,system 200 can employ the generation of a Bill of Materials, runtimeanalysis and build time analysis to identify unused third partysoftware. Also, exemplary embodiments enable software developers to benotified if a license of third party software changes. In oneembodiment, system 200 can provide notification of the change in thelicense of third party software if a license model change is detectedbetween versions of open source.

FIG. 2C shows the relationship between third party software management,software characteristics examination components and third party softwarecharacteristics according to one embodiment. In one embodiment, thirdparty software management utilizes third party software characteristicexamination components (e.g., 205 in FIG. 2A) to detect third partysoftware characteristics. Referring to FIG. 2C, characteristicsexamination components can include but are not limited to currencyexamination component 271, consistency examination component 273,security score examination component 275, usage and bill of materialexamination component 277, versions examination component 279, licensetype examination component 281 and legal examination component 281. Inone embodiment, currency examination component 271, security scoreexamination component 275 versions examination component 279 and licensetype examination component 281 obtain third party softwarecharacteristics information from an examination of the software build.

Referring to FIG. 2C, currency examination component 271 determines thecurrency of third party software elements of a software build.Characteristics that are detected by currency examination component 271include but are not limited to whether the third party software isdeprecated 271 a, whether the third party software is no longersupported 271 b and whether the third party software is aging 271 c. Thecharacteristics of aging third party software that are detected caninclude but are not limited to whether the aging third party software isa minor version 271 d or a major version 271 e.

Consistency examination component 273 determines if third party softwarethat is used in a build is consistent. Characteristics that areidentified by consistency examination component 273 can include but arenot limited to whether similar libraries are used 273 a and whetheralternative libraries are used 273 b (or should be used).

Security score examination component 275 determines if third partysoftware has a published security score 275 a, e.g., a commonvulnerabilities and exposures (CVE) score. From the CVE 275 a, bug fixes275 b can be determined using an internal database. Moreover, from theCVE 275 a, major fixes in the examined third party software can beidentified.

Usage and bill of material examination component 277 determines thirdparty software usage and bill of materials. In particular, it determinesif third party software is one of, declared and used 277 a, declared andnot used 277 b and not declared and used 277 c. In addition, in oneembodiment, usage and bill of material examination component 277 alsodetermines transitive dependencies.

Version examination component 279 identifies the third party softwareversions that are a part of a build and determines whether there aremultiple versions of the same software 279 a or incompatible versions ofsoftware 279 b in a build.

License type examination component 281 determines the type of licensethat third party software has. In one embodiment, license typeexamination component 281 determines if a license is open source 281 aor paid 281 b. Legal examination component 283 determines if third partysoftware has been legally approved 283 a and export regulation 283 b.

Third party software management 270 is the automated management of thirdparty software by developers and includes parts of system 200 such asthird party rules engine 209 and threat assessment database 215 and isbased on the information that is provided by the third partycharacteristics examination components and information that may becustomized such as company third party policy definitions (see FIG. 2A,219, 221 and 225).

FIG. 3 shows a flowchart 300 of the steps performed in a method 300 forautomatically assessing operational risks and mitigating operationalrisks associated with using a software component in a softwareapplication according to one embodiment. The flowchart includesprocesses that, in one embodiment can be carried out by processors andelectrical components under the control of computer-readable andcomputer-executable instructions. Although specific steps are disclosedin the flowcharts, such steps are exemplary. That is the presentembodiment is well suited to performing various other steps orvariations of the steps recited in the flowchart.

At 301, one or more software components of a software application areaccessed. In one embodiment, from the accessed one or more softwarecomponents, software component characteristic information is generated.In one embodiment, the software components can be third party softwarecomponents. In one embodiment, the software components can be thirdparty software components of a build that is prepared by a softwaredeveloper(s).

At 303, responsive to accessing the one or more software components,receiving software component characteristic information about each ofthe one or more software components. In one embodiment, the softwarecomponent characteristic information includes information about acharacteristic of a software component that is related to an operationalrisk associated with using the software component in the softwareapplication. In one embodiment, the software component characteristicinformation can be determined by software component characteristicdetection components. In one embodiment, as described herein, softwarecomponent characteristic information can be accessed by a third partyrules engine that determines operational risks based on thecharacteristics.

At 305, responsive to receiving the software component characteristicinformation, generating operational risk assessment information usingone or more rules and based on the software component characteristicinformation. In one embodiment, operational risk assessment informationcan be generated by a rules engine. In one embodiment, the rules enginecan generate the operational risk assessment information based at leastin part on rules derived from policy definitions provided by a softwaredeveloper organization.

At 307, the generated operational risk assessment information is output,wherein at least one step of the method is performed by a processor. Inone embodiment, the operational risk assessment information can bestored in a database in order to benefit subsequent operational riskassessments. In addition, operational risk mitigation information isgenerated based on the automatically generated operational riskassessment information.

In one embodiment, third party software policy definition informationcan be accessed, where the third party software policy definitioninformation includes information defining one or more policies foroperating a third party software component. Moreover, approved softwarecomponent information is accessed, where the approved software componentinformation is information identifying third party software componentsthat are approved for use in the software application. In oneembodiment, the aforementioned rules are determined at least in partresponsive to accessing the third party software policy definitioninformation and approved software component information. The riskassessment information using one or more of the determined rules.

In one embodiment, software characteristic information comprisessoftware currency information, software consistency information,software security information, software license type information andsoftware version information. In one embodiment, the threat assessmentinformation includes information indicating when an operational riskwill increase or decrease. In one embodiment, the risk mitigationinformation comprises information that prioritizes third party productsfor upgrade.

Software companies rely on open source and paid third party software to:accelerate software development cycles, reduce software maintenancecost, stay on top of the latest technology advancements etc. Someconventional software platforms use hundreds of third party softwareelements (where an element is third party software for a particularversion). Proper management of third party software in this environmentrepresents a challenge with a set of risks. Exemplary embodimentsprovide a mechanism to: identify risks associated with third partymanagement in a normalized way, provide risk mitigation plans and raiserisk awareness proactively to anticipate an issue (end of life of thirdparty products).

FIG. 4 is a diagram of an example computing system 400 that may be usedto implement some example embodiments of a resource identificationsystem. The computing system 400 may be implemented on any computingdevice or plurality of computing devices that may be configured toimplement one or more example embodiments. By way of non-limitingexample, in some embodiments, the computing system 400 may beimplemented on a user terminal and/or a computing platform(s) of aconverged infrastructure.

The computing system may include a plurality of elements, such asprocessing circuitry 410, mass storage 418, communication interface 420,and user interface 422, which may be interfaced via a system bus 416. Itwill be appreciated that the components, devices or elements illustratedin and described with respect to FIG. 4 below may not be mandatory andthus some may be omitted in certain embodiments. Additionally, thecomputing system 400 of some embodiments may include further ordifferent components, devices or elements beyond those illustrated inand described with respect to FIG. 4.

Further, while FIG. 4 illustrates an architecture including elementsinterfaced via the system bus 416, it will be appreciated that in someexample embodiments, elements of the computing system 400 may beimplemented in a distributed computing environment in which elements maybe distributed across a plurality of computing devices, which may be incommunication with each other, such as via a network, to providefunctionality of the computing system 400. As such, in some exampleembodiments, elements of the computing system 400 may be communicativelycoupled via a network in addition to or in lieu of the system bus 416.

The computing system 400 of some example embodiments may implement anoperating system(s), such as MICROSOFT WINDOWS™, UNIX™, LINUX™, IBMz/OS™, CISCO™ INTERNETWORK OPERATING SYSTEM™ (IOS), CISCO™ CATALYST™OPERATING SYSTEM (CatOS), CISCO NX-OS, EMC™ ISILON OneFS™ OPERATINGSYSTEM, NETAPP™ DATA ONTAP™, or other known operating systems. It shouldbe appreciated; however, that in some embodiments, one or more aspectsof the computing system 400 may be implemented on and/or integrated witha virtualized computing system, such as may be provided by a convergedinfrastructure.

In some example embodiments, the computing system 400 may includeprocessing circuitry 410 that is configurable to perform actions inaccordance with one or more example embodiments disclosed herein. Inthis regard, the processing circuitry 410 may be configured to performand/or control performance of one or more functionalities of a systemfor third party software risk analysis and mitigation (e.g., 200 in FIG.1A), in accordance with various example embodiments. Thus, theprocessing circuitry 410 may be configured to perform data processing,application execution and/or other processing and management servicesaccording to one or more example embodiments.

In some example embodiments, the processing circuitry 410 may include aprocessor 412 and, in some embodiments, such as that illustrated in FIG.4, may further include memory 414. The processing circuitry 410 may bein communication with (e.g., via system bus 416) and/or otherwisecontrol mass storage 418, communication interface 420, and/or userinterface 422.

The processor 412 may be embodied in a variety of forms. For example,the processor 412 may be embodied as various hardware processing meanssuch as a microprocessor, a coprocessor, a general purpose processor, acontroller or various other computing or processing devices includingintegrated circuits (e.g., a logic device), such as an ASIC (applicationspecific integrated circuit), an FPGA (field programmable gate array),some combination thereof, or the like. Although illustrated as a singleprocessor, it will be appreciated that the processor 412 may comprise aplurality of processors. The plurality of processors may be in operativecommunication with each other and may be collectively configured toperform one or more functionalities to support determination of aconfiguration of a converged infrastructure in accordance with variousembodiments. In some embodiments in which the computing system 400 isembodied as a plurality of computing devices, a plurality of processors,which may collectively form the processor 412, may be distributed acrossa plurality of computing devices that may be in operative communicationwith each other directly and/or via a network. In some exampleembodiments, the processor 412 may be configured to execute instructionsthat may be stored in a memory, such as the memory 414 and/or the massstorage 418 and/or that may be otherwise accessible to the processor412. As such, whether configured by hardware or by a combination ofhardware and software, the processor 412 may be capable of performingoperations according to various embodiments while configuredaccordingly.

In embodiments including the memory 414, the memory 414 may include readonly memory (ROM), random access memory (RAM), and/or the like. The massstorage 518 may include one or more memory and/or other storage devices,which may include fixed (e.g., a fixed hard disc drive, storage array,fixed flash memory device, and/or the like) and/or removable memorydevices (e.g., a floppy disc drive, a removable flash memory device, anoptical disc drive, and/or other removable memory device). The massstorage 418 may provide a persistent data storage device. In someexample embodiments, the mass storage 418 may be configured to provide abackup storage. The mass storage 418 may include a memory deviceimplemented locally to the computing system 400 and/or a memory deviceremote to the computing system 400, which may be communicatively coupledwith the computing system 400, such as via a network. In someembodiments in which the computing system 400 is embodied as a pluralityof computing devices, the memory 414 and/or mass storage 418 may includea plurality of memory devices, which may be distributed across aplurality of computing devices that may be in operative communicationwith each other directly and/or via a network to form the computingsystem 400.

In some embodiments, the memory 414 and/or the mass storage 418 mayprovide a non-transitory computer-readable storage medium that may storecomputer program instructions that may be executed by the processor 412.In this regard, the memory 414 and/or mass storage 418 may be configuredto store information, data, applications, instructions and/or the likefor enabling the computing system 400 to carry out various functions inaccordance with one or more example embodiments. Applications that maybe executed by the processor 412 may also be in the form of modulatedelectronic signals that may be accessed via a network modem or othernetwork interface of the computing system 400.

The computing system 400 may further include a communication interface420. The communication interface 420 may enable the computing system 400to communicate (e.g., over a network or other communication interface)with another computing device or system. In this regard, thecommunication interface 420 may include one or more interface mechanismsfor enabling communication with other devices and/or networks. As such,the communication interface 420 may include, for example, an antenna (ormultiple antennas) and supporting hardware and/or software for enablingcommunications with a wireless communication network (e.g., a cellularnetwork, wireless local area network, and/or the like) and/or acommunication modem or other hardware/software for supportingcommunication via cable, digital subscriber line (DSL), USB, FireWire,Ethernet, one or more optical transmission technologies, and/or otherwireline networking methods.

In some example embodiments, the computing system 400 may include theuser interface 422. It will be appreciated, however, that in someexample embodiments, one or more aspects of the user interface 422 maybe omitted, and in some embodiments, the user interface 422 may beomitted entirely. The user interface 422 may be in communication withthe processing circuitry 410 to receive an indication of a user inputand/or to provide an audible, visual, mechanical, or other output to auser. As such, the user interface 422 may include, for example, akeyboard, a mouse, a joystick, a display, a touch screen display, amicrophone, a speaker, one or more biometric input devices, and/or otherinput/output mechanisms.

Embodiments described herein may be practiced with various computersystem configurations including blade devices, cloud systems, convergedinfrastructure systems, rack mounted servers, switches, storageenvironments, hand-held devices, tablets, microprocessor systems,microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. Some embodiments may alsobe practiced in distributed computing environments where tasks areperformed by remote processing devices that are linked through one ormore networks, such as one or more wireline networks and/or one or morewireless networks.

A computer program product may be used to implement a resourceidentification system, in some example embodiments. A computer programproduct embodiment may include a machine-readable, non-transitory(non-volatile) storage medium (media) having instructions storedthereon/in, which can be used to program a computer to perform any ofthe processes of the embodiments described herein. Computer code foroperating and configuring a resource identification system is preferablydownloaded and stored on a hard disk, although the entire program code,or portions thereof, may also be stored in any other volatile ornon-volatile memory medium or device as is well known, such as a readonly memory (ROM) or random access memory (RAM), or provided on anymedia capable of storing program code, such as any type of rotating orsolid state media, or any type of media or device suitable for storinginstructions and/or data. Additionally, the entire program code, orportions thereof, may be transmitted and downloaded from a softwaresource over a transmission medium, e.g., over the Internet, or fromanother server, as is well known, or transmitted over any otherconventional network connection as is well known (e.g. extranet, virtualprivate network (VPN), local area network (LAN), etc.) using anycommunication medium and protocols (e.g. transmission controlprotocol/internet protocol (TCP/IP), hypertext transport protocol(HTTP), HTTP secure (HTTPS), Ethernet, etc.) as are well known. It maybe appreciated that computer code for implementing embodiments of thepresent invention can be implemented in any programming language thatcan be executed on a client system and/or server or server system suchas, for example, C, C++, hypertext markup language (HTML), any othermarkup language, Java™, JavaScript, ActiveX, any other scriptinglanguage, such as VB Script, and many other programming languages as arewell known may be used.

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which thesedisclosed embodiments pertain having the benefit of the teachingspresented in the foregoing descriptions and the associated drawings.Therefore, it is to be understood that embodiments of the invention arenot to be limited to the specific embodiments disclosed and thatmodifications and other embodiments are intended to be included withinthe scope of the invention. Moreover, although the foregoingdescriptions and the associated drawings describe example embodiments inthe context of certain example combinations of elements and/orfunctions, it should be appreciated that different combinations ofelements and/or functions may be provided by alternative embodimentswithout departing from the scope of the disclosure. In this regard, forexample, different combinations of elements and/or functions than thoseexplicitly described above are also contemplated within the scope of thedisclosure. Although specific terms are employed herein, they are usedin a generic and descriptive sense only and not for purposes oflimitation.

It should be understood that although the terms first, second, etc. maybe used herein to describe various steps or calculations, these steps orcalculations should not be limited by these terms. These terms are onlyused to distinguish one operation or calculation from another. Forexample, a first calculation may be termed a second calculation, and,similarly, a second step may be termed a first step, without departingfrom the scope of this disclosure. As used herein, the term “and/or” andthe “/” symbol includes any and all combinations of one or more of theassociated listed items.

As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises,”“comprising,” “includes,” and/or “including,” when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. Therefore, the terminology usedherein is for the purpose of describing particular embodiments only andis not intended to be limiting.

What is claimed is:
 1. A method for automatically assessing operationalrisks and mitigating operational risks associated with using a softwarecomponent in a software application, comprising: accessing softwarecomponents comprising the software application; responsive to accessingthe software components, receiving software component characteristicinformation about each software component of the software components,including information about a characteristic of the software componentthat is related to an operational risk associated with using thesoftware component in the software application; determining that a thirdparty software component of the software components is approved for usein the software application based on the software componentcharacteristic information; generating operational risk assessmentinformation using one or more rules and based on the software componentcharacteristic information; outputting the operational risk assessmentinformation requiring that the third party software component beupgraded; and generating operational risk mitigation information basedon the operational risk assessment information, and includinginformation that prioritizes the third party software component forupgrade over at least another software component of the softwarecomponents, wherein at least one step of the method is performed by aprocessor.
 2. The method of claim 1, further comprising: accessing thirdparty software policy definition information, the third party softwarepolicy definition information comprising information defining one ormore policies for operating the third party software component; andaccessing approved software component information, the approved softwarecomponent information being information identifying third party softwarecomponents that are approved for use in the software application.
 3. Themethod of claim 2, further comprising determining the one or more rulesat least in part responsive to accessing the third party software policydefinition information and the approved software component information;and generating the risk assessment information using one or more of thedetermined rules.
 4. The method of claim 1 wherein the softwarecomponent characteristic information comprises software currencyinformation, software consistency information, or software securityinformation.
 5. The method of claim 1 wherein the software componentcharacteristic information comprises software license type informationor software version information.
 6. The method of claim 1 wherein theoperational risk assessment information includes information indicatingwhen an operational risk will increase or decrease.
 7. A computerprogram product for automatically assessing operational risks andmitigating operational risks associated with using a software componentin a software application, the computer program product comprising anon-transitory computer-readable storage medium having programinstructions stored thereon, which when executed by at least oneprocessor, cause the at least one processor to perform a methodcomprising: accessing software components comprising the softwareapplication; responsive to accessing the software components, receivingsoftware component characteristic information about each softwarecomponent of the software components, including information about acharacteristic of the software component that is related to anoperational risk associated with using the software component in thesoftware application; determining that a third party software componentof the software components is approved for use in the softwareapplication based on the software component characteristic information;generating operational risk assessment information using one or morerules and based on the software component characteristic information;outputting the operational risk assessment information requiring thatthe third party software component be upgraded; and generatingoperational risk mitigation information based on the operational riskassessment information, and including information that prioritizes thethird party software component for upgrade over at least anothersoftware component of the software components, wherein at least one stepof the method is performed by a processor.
 8. The computer programproduct of claim 7, further comprising: accessing third party softwarepolicy definition information, the third party software policydefinition information comprising information defining one or morepolicies for operating the third party software component; and accessingapproved software component information, the approved software componentinformation being information identifying third party softwarecomponents that are approved for use in the software application.
 9. Thecomputer program product of claim 8, further comprising determining theone or more rules at least in part responsive to accessing the thirdparty software policy definition information and the approved softwarecomponent information; and generating the risk assessment informationusing one or more of the determined rules.
 10. The computer programproduct of claim 7 wherein the software component characteristicinformation comprises software currency information, softwareconsistency information, or software security information.
 11. Thecomputer program product of claim 7 wherein the software componentcharacteristic information comprises software license type informationor software version information.
 12. The computer program product ofclaim 7 wherein the operational risk assessment information includesinformation indicating when an operational risk will increase ordecrease.
 13. A computer implemented system for automatically assessingoperational risks and mitigating operational risks associated with usinga software component in a software application, the system comprising:at least one processor; and at least one memory storing computer programcode, wherein the at least one memory and stored computer program codeare configured, with the at least one processor, to cause the system toat least: access software components comprising the softwareapplication; responsive to accessing the software components, receivesoftware component characteristic information about each softwarecomponent of the software components, including information about acharacteristic of the software component that is related to anoperational risk associated with using the software component in thesoftware application; determine that a third party software component ofthe software components is approved for use in the software applicationbased on the software component characteristic information; generateoperational risk assessment information using one or more rules andbased on the software component characteristic information; output theoperational risk assessment information requiring that the third partysoftware component be upgraded; and generate operational risk mitigationinformation based on the operational risk assessment information, andincluding information that prioritizes the third party softwarecomponent for upgrade over at least another software component of thesoftware components, wherein at least one step of the method isperformed by a processor.
 14. The system of claim 13, wherein the systemis further caused to: access third party software policy definitioninformation, the third party software policy definition informationcomprising information defining one or more policies for operating thethird party software component; and access approved software componentinformation, the approved software component information beinginformation identifying third party software components that areapproved for use in the software application.
 15. The system of claim14, wherein the system is further caused to determine the one or morerules at least in part responsive to accessing the third party softwarepolicy definition information and the approved software componentinformation; and generate the risk assessment information using one ormore of the determined rules.
 16. The system of claim 13 wherein thesoftware component characteristic information comprises softwarecurrency information, software consistency information, or softwaresecurity information.
 17. The system of claim 13 wherein the softwarecomponent characteristic information comprises software license typeinformation or software version information.
 18. The system of claim 13wherein the operational risk assessment information includes informationindicating when an operational risk will increase or decrease.